Data Carrier Detect
 | This article needs additional citations for verification. (March 2023) |
Data Carrier Detect (DCD) or Carrier Detect (CD) is a control signal present inside an RS-232 serial communications cable that goes between a computer and another device, such as a modem. This signal is a simple "high/low" status bit that is sent from a data communications equipment (DCE) to a data terminal equipment (DTE), i.e., from the modem or other peripheral to a computer in a typical scenario. It is present on virtually all PC serial ports - pin 1 of a nine-pin (DE9) serial port, or pin eight over a 25-pin (DB25) port. Its purpose varies depending on the device connected, but the most specific meaning is to indicate when a modem is connected to another remote modem via telephone lines.
The word "carrier" is a reference to the analog carrier signal generated by a modem, which is modulated to carry the data. On a data modem, the carrier's loss equates to the connection's termination.
Much like the Ring Indicator signal, on a PC's serial port, changes to the DCD signal state can generate a hardware interrupt that can be captured by the processor any time the DCD signal changes state, preventing the PC from needing to constantly poll the pin.
As used on modems
[edit]DCD is very important on modems, as it is the computer's primary way to find out that the modem has lost its connection to the remote host. Aside from intentional disconnects, modems can lose their connection for a variety of reasons unexpectedly - such as the phone line being disconnected. It is possible to use a modem without the DCD signal, however the only way for the computer to know that a connection is disconnected is by the modem transmitting the words "NO CARRIER" over the data lines. Because the words "NO CARRIER" are also a message that could appear in the context of a normal data session (for example, if typed by a person on the remote end), there is no positive way for a computer program to differentiate the words being sent over the connection versus from the modem.
External modems with LED status lights usually have a light labeled "CD" (carrier detect). This status light is directly coupled with what the modem is sending the DCD line.
By default, when a modem is powered up, the DCD signal is deasserted. It is not asserted until the modem either makes an outgoing call, or answers an incoming call, and then connects with a data modem on the other end. The signal is asserted at the same time the modem reports its CONNECT message, and stays asserted until the call is disconnected (either intentionally or because of a fault in the line). DCD is deasserted once the local modem is no longer receiving carrier from the remote modem, regardless of which side initiated the disconnect. So long as the DCD signal is high, the computer can assume that any data coming from the modem was sent from the remote side.
Virtually all newer modems allowing the behavior of the DCD signal to be configured. Typical options available include "always assert DCD", "assert DCD only when connected", and "always assert DCD except immediately after sensing a disconnect".
The meaning of DCD differs when the modem is in fax or voice modes. In these modes, its importance is diminished.[how?]
As used with null modems
[edit]Frequent use of a serial port is for a direct computer-to-computer connection. This requires an adapter called a null modem, which isn't actually a modem in the traditional sense, but rather a connector plug that simply crosses the complementary pins on two serial ports so the two sides can communicate. A null modem typically connects the DTR output of each computer to both the DCD and DSR inputs of the other.
When used in this scenario, DCD is used to simply detect the presence and/or readiness of the other side to start a session. For example, on Windows PCs, the DTR output is kept low until some program is run to access the serial port and raise the DTR signal high. The remote side will sense this as the DCD input going high. Some equipment will recognize the transition alone as the beginning of a session. Other equipment (such as the console port of a router) may expect characters to be transmitted,[clarification needed] but the DCD signal high is still a prerequisite for every communication.[clarification needed]
PPS (Pulse per second) timing use
[edit]The serial DCD pin can be used to accurately detect a PPS signal, as described in RFC 2783:[1]
One convenient means to provide a PPS signal to a computer system is to connect that signal to a modem-control pin on a serial-line interface to the computer. The Data Carrier Detect (DCD) pin is frequently used for this purpose. Typically, the time-code output of the time source is transmitted to the computer over the same serial line. The computer detects a signal transition on the DCD pin, usually by receiving an interrupt and records a timestamp as soon as possible.
As used with other hardware
[edit]In Linux, each serial port is referenced by two device names - one being (for the first serial port) /dev/ttyS0 versus /dev/cua0. Although these both refer to the same physical port, one important distinction between the way Linux treats these two device names has to do with the DCD line. When ttyS0 is waited on in a system call, Linux assumes that since this device is for receiving telephone calls, it will put a process to sleep— figuring that so long as DCD is low, there is nothing to do. When cua0 is used - as it is when placing telephone calls - Linux assumes that the software needs to access the port while DCD is low for the purpose of dialing the number, so this blocking behavior doesn't exist. Nevertheless, there is a control mode flag called CLOCAL which is what actually activates or deactivates this behavior, and by default, the flag is set for cua0 but not for ttyS0. An application that insists on using a "tty" port versus a "cua" port is an example of one that might require a jumper wire to force DCD high in order to work properly.[2]
References
[edit]- ^ Mogul, J.; Mills, D.; Brittenson, J.; Stone, J.; Windl, U. (March 2000). "Introduction". Pulse-Per-Second API for UNIX-like Operating Systems. IETF. p. 3. doi:10.17487/RFC2783. RFC 2783.
- ^ Coldwell, Charles Terminal concepts in GNU/Linux Archived 2008-04-29 at the Wayback Machine